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(57) Abstract: A method of performing a public/private key operation is disclosed comprising: generating a private and public key 
pair, the public key having a lifetime; selecting a plurality of intervals within the lifetime and a plurality of respective identifiers, each 
interval being associated with a said identifier; and having a trusted third party generate a public key certificate which includes the 
public key and a final identifier, the identifiers being selected so that it is relatively difficult to derive an identifier associated with a 
said interval from the final identifier but relatively easy to derive the final identifier from an identifier associated with a said interval, 
a said identifier being provided by a user with any matter signed or otherwise operated upon using the private key in the associated 
interval to confirm the validity of ihe certificate in that interval. A forward-secure digital signature scheme in which transactions for 
validity periods both before and after the current period remain secure even if the private key for the current period is compromised 
is also disclosed. 
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PUBLIC KEY CRYPTOGRAPHY AND A FRAMEWORK THEREFOR 

BACKGROUND AND FIELD OF THE INVENTION 

5 This invention relates to public key cryptography, more particularly to verification of a 
public key. 

Public-key cryptography has been widely used in various security applications since its 
invention by Diffie and Hellman in 1976. In contrast to conventional cryptography, a 
10 pair of keys are used: a private key that is kept confidential by a certain party, and a 
public key that is available to the public. Depending on the public-key cryptographic 
algorithm, the public key can be used to encrypt a message or to verify a signature while 
the corresponding private key could be used to decrypt the cipher text or to generate the 
signature. It is computationally hard to derive the private key from the public key. 

15 

Digital signature is one of the most important applications of public-key cryptography, 
and is the fundamental mechanism for authentication and non-repudiation services. The 
signer can generate a digital signature of a message using his private key. The receiver 
can check the origin and integrity of the message by verifying the digital signature with 
20 the corresponding public key. Moreover, if the private key is only known to the signer, 
the signer cannot deny originating the signature since other parties are unable to forge 
the signature without the private key. 
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To determine the origin of a signed message, the verifier first needs to make sure what 
is the claimed signer's public key. Public-key certificates play an important role in 
binding the public key with the identity of the owner of the corresponding private key. 
X.509 is an industry standard which defines the format of a public-key certificate. The 
5 elements of a public-key certificate include the public key of an entity, the entity's 
distinguished identifier, an expiry date of the certificate, and an identifier of the 
cryptographic algorithm with which the public key is to be used. To ensure the 
authenticated identity of a certificate owner, the certificate needs to be issued by a 
trusted third party (TTP) called the certification authority (CA). 

10 

As a private key might be compromised before the corresponding public-key 
certificate's scheduled expiry date, any party holding a compromised key can forge the 
signature. Therefore, additional security mechanisms are needed to prevent this. A 
straightforward approach is that the owner of the certificate requests the issuing CA to 
15 revoke the certificate. The certificate revocation information will be accessible to public 
thus the relevant users will be aware that an apparently valid certificate is no longer 
valid. 



The IETF PBQX Working Group is developing an Internet standard to support an X.509 
20 based public-key infrastructure (PKI) (R. Housley, W. Ford, W. Polk, and D. Solo. 
"Internet X.509 public key infrastructure certificate and CKL profile " . RFC 2459, 
January 1999). The PKI provides a framework for services relating to 
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issuing public-key certificates and distributing revocation information. Certificate 
revocation and validation is a significant burden to the PKI. 

It is an object of the invention to provide a public key cryptographic framework which 
5 alleviates at least one of the disadvantages of the prior art and/or provides the public 
with a useful choice. 

STIMM AttV PIT TUT? INVENTION 

10 According to the invention in a first aspect, there is provided a method of performing a 
public/private key operation comprising the steps of: generating a private and public key 
pair, the public key having a lifetime; selecting a plurality of intervals within the 
lifetime and a plurality of respective identifiers, each interval being associated with a 
said identifier; and having a trusted third party generate a public key certificate which 

15 includes the public key and a final identifier, the identifiers being selected so that it is 
relatively difficult to derive an identifier associated with a said interval from the final 
identifier but relatively easy to derive the final identifier from an identifier associated 
with a said interval, a said identifier being provided by a user with any matter signed or 
otherwise operated upon using the private key in the associated interval to confirm the 

20 validity of the certificate in that interval. 



Preferably, a user of the private key holds the certificate or the certificate is held in a 
public location. One or more identifiers or means from which the identifiers are 
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generated may be stored on a remote server with a user wishing to encrypt matter using 
the private key typically either obtaining the identifier for the current period from the 
server or obtaining said means from the server and generating the identifier using the 
means, with the user and server preferably communicating via a secure channel. 

The identifiers are preferably generated by recursive application of a one-way hash 
function to a root. 



The user may obtain a time stamped version of the encrypted matter to be accompanied 
10 by the identifier and/or the private key may have validity within a time period, the user 
sending a time of encryption with the encrypted matter and/or each interval may have 
associated therewith an interval private key, the interval private keys being each usable 
together with the public key in a public/private key encryption/decryption operation, the 
interval keys being such that it is relatively easy to derive a later interval key from an 
15 earlier interval key but relatively difficult to derive an earlier interval key from a later 
one. 

In the claimed method typically a third party operates on the current interval identifier to 
derive the final identifier to confirm the validity of the certificate in the current interval, 
20 together with any additional authentication/verification procedures as mentioned by way 
of example in the preceding paragraph. 
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A third party wishing to confirm the validity of the certificate may request from the user 
the identifier of the current time period and determines if the final identifier of the 
certificate can be derived from the current identifier. The third party may then use the 
public key verified by the certificate to encrypt matter to send to the user. 

5 

According to the invention in a second aspect, there is provided a method of conducting 
a public key transaction comprising the steps of: generating a public and private key 
pair, the private key being held by the user and the public key being accessible to a party 
to the transaction and having associated therewith a public key certificate issued by a 

10 trusted third party; sending to the party matter signed or otherwise operated upon using 
the private key by the user together with a matter identifier; the certificate including a 
certificate identifier , the identifiers being such that it is relatively easy to derive the 
certificate identifier from the matter identifier but relatively difficult to derive the matter 
identifier from the certificate identifier; and operating on the matter identifier provided 

15 by the user to derive the certificate identifier to confirm the validity of the certificate. 



According to the invention in a third aspect, there is provided a public key certificate 
issued by a trusted third party comprising a public key, a final identifier and means 
defining validity periods between a start date and a finish date, a plurality of identifiers 
20 not forming part of the certificate each being associated with a said validity period and 
arranged to accompany matter signed or otherwise operated upon by the user using a 
private key associated with the public key within the respective validity period and 
wherein the plurality of identifiers are selected so that it is relatively easy to derive the 
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final identifier from one of the plurality of identifiers but relatively difficult to derive 
any of the plurality of identifiers from the final identifier, whereby the validity of the 
public key certificate within the validity period may be confirmed by operating upon the 
identifier provided by the user with the matter . 

5 

Preferably the identifiers are the product of the recursive application of a one-way hash 
function to a root. Said means may include a start date and the number and duration of 
renewal intervals, and the identifier and said means are preferably integrated into one or 
more extensions of the certificate, typically in at least one of: a private extension; a 
10 subject key id; a subject alternative name. The certificate is preferably constituted using 
X.509. 



According to the invention in a fourth aspect, there is provided a public/private key 
cryptography framework in which matter operated upon using a private key of a public 

15 and private key pair is associated with a separate authentication which accompanies the 
matter, the authentication being related to a verifier, the verifier and public key being 
available to a recipient of the encrypted matter and accompanying authentication in the 
form of a public key certificate issued by a trusted third party and the arrangement being 
such that the verifier may be derived from the authentication but not vice versa to 

20 confirm the validity of the public key certificate. 
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The public key and verifier are preferably bound together in a public key certificate, and 
the certificate once generated may reside with a user of the private key and accompany 
any message signed with the private key and sent by the user. 

5 The described embodiment discloses a public-key framework that avoids the certificate 
revocation in authentication, non-repudiation, and public-key encryption services. Either 
the certificate owner or his manager can control the validity of his certificate that has an 
extensible expiry date. The undeniable information that extends the certificate's expiry 
date is released by the certificate owner to the certificate verifiers directly. The 

10 certificate verifiers can determine whether the certificate is valid without contacting the 
CA or other trusted third parties. 



According to the invention in a fifth aspect, there is provided a method of performing a 
public/private key operation comprising the steps of: 
15 generating a public key and a root private key, the public key having a lifetime; 

operating on the root private key to generate a respective plurality of interval private 
keys, the interval private keys being each usable together with the public key in a 
public/private key operation; 

selecting a plurality of intervals within the lifetime and a respective plurality of 
20 identifiers, each interval being associated with an identifier and a said interval private 
key; 

associating the public key with a final identifier; 
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the identifiers being such that it is relatively difficult to derive an identifier associated 
with a said interval from the final identifier but relatively easy to derive the final 
identifier from an identifier associated with a said interval ; and the interval keys being 
such that it is relatively easy to derive a later interval key from an earlier interval key 
5 but relatively difficult to derive an earlier interval key from a later one. 

The public key and final identifier preferably form part of a public key certificate issued 
by a trusted third party. 

10 The identifiers may be generated by recursive application of a one-way hash function to 
a root 

Within a current said interval, a user may send, to a third party, matter encrypted using 
the private key associated with the current interval, the identifier associated with the 
1 5 current interval being provided with the encrypted matter with the third party operating 
on the current interval identifier to derive the final identifier to confirm the validity of 
the private key and hash value in the current interval. 



20 



In the described embodiment a forward-secure digital signature scheme is disclosed in 
which transactions for validity periods both before, and after the current period remain 
secure even if the private key for the current period is compromised. 
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BRIEF DESCRIPTION OF THE DRAWINGS 
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An embodiment of the invention will now be described, by way of example, with 
reference to accompanying drawings in which: 

Figure 1 illustrates certificate expiry date extension using the embodiment of the 
invention; 



Figure 2 illustrates public key framework; 

Figure 3 illustrates a procedure for validating signatures using a forward secured digital 
signature scheme; and 



Figure 4 illustrates how the embodiment of present invention may be integrated with the 
15 X.509 industry standard which defines the format of a public key certificate. 



DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 



Before describing the preferred embodiment of the invention, two standardized 
20 certificate revocation mechanisms in the IETF will be described namely: 

• CRL — Certificate Revocation List, which provides periodic revocation 
information. 
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• OCSP - On-line Certificate Status Protocol, which provides timely . 
revocation information. 

Certificate Revocation List (CRL) 

A CRL is a time-stamped list of serial numbers or other certificate identifiers for those 
certificates that have been revoked by a particular CA. The CRL is signed by the 
relevant CA and made freely available in a public repository. Updates should be issued 
at regular intervals, even if the list has not changed (thus enabling users possessing a 
CRL to check that it is the current one). The revoked certificates should remain on the 
list until their scheduled expiry date. 

X.509 v2 CRL format profiled for Internet use in RFC2459 defines the required and 
optional fields. The required fields identify the CRL issuer, the algorithm used to sign 
15 the CRL, the date and time the CRL was issued, and the date and time by which the CA 
will issue the next CRL. Optional fields include lists of revoked certificates and CRL 
extensions. The revoked certificate list is optional to support the case where a CA has 
not revoked any unexpired certificates that it has issued. 

20 Certificates revoked by the CA are uniquely identified by the certificate serial number. 
The date on which the revocation occurred is specified. Additional information may be 
supplied in CRL entry extensions which include 

• Reason Code - identifies the reason for the certificate revocation. 



5 



10 
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• Hold Instruction Code - indicates the action to be taken after encountering a 
certificate that has been placed on hold. 

• Invalidity Date - provides the date on which it is known or suspected that the 
private key was compromised or that the certificate otherwise became 

5 invalid. 

• Certificate Issuer - identifies the certificate issuer associated with an entry in 
an indirect CRL. 

CRL extensions provide methods for associating additional attributes with CRLs. The 
10 X.509 v2 CRL format also allows communities to define private extensions to carry 
information unique to those communities. Each extension in a CRL may be designated 
as critical or non- critical. A CRL validation must fail if it encounters a critical 
extension which it does not know how to process. However, an unrecognized non- 
critical extension may be ignored. The extensions used within Internet CRLs include 
1 5 • Authority Key Identifier - identifies the public key corresponding to the 

private key used to sign a CRL. 

• Issuer Alternative Name - allows additional identities to be associated with 
the issuer of the CRL. 

• CRL Number - allows users to easily determine when a particular CRL 
20 supersedes another CRL. 

• Delta CRL Indicator - contains the changes between the base CRL and the 
current CRL issued along with the delta-CRL. 
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particular CRL. 
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identifies the CRL distribution point for a 



Operational protocols that deliver CRLs to client systems could be built based on a 
5 variety of different means such as LDAP, HTTP, FTP, and X.500. 

An advantage of this revocation method is that CRLs may be distributed by exactly the 
same means as certificates themselves, namely, via untrusted communications and 
server systems. One limitation of the CRL revocation method is that the time granularity 
10 of revocation is limited to the CRL issue period. For example, if a revocation is reported 
now, that revocation will not be reliably notified to certificate-using systems until the 
next periodic CRL is issued — this may be up to one hour, one day, or one week 
depending on the frequency that the CA issues CRLs. 

1 5 On-line Certificate Stating Protocol (OCSP) 

The OCSP is described in M. Myers, R. Ankney, A. Malpani, S. Galperin, and C. 
Adams. "X.509 Internet public key infrastructure on-line certificate status protocol 
(OCSP) RFC 2560, June 1999 as a supplement to checking against a 
20 periodic CRL, it may be necessary to obtain timely information regarding the revocation 
status of a certificate. The OCSP enables applications to determine the state of an 
identified certificate. An OCSP client issues a status request to an OCSP responder and 
suspends acceptance of the certificate in question until the responder provides a 
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response. The OCSP responder must be one of the following parties. 

• The CA who issued the certificate in question, 

• A trusted responder whose public key is trusted by the requester, or 

• A designated responder who holds a specially marked certificate issued 
directly by the CA, indicating that the responder may issue OCSP responses 
for that CA. 



Upon receipt of a request, the OCSP responder either returns a definitive response, or 
produces an error message. All definitive response messages should be digitally signed. 
10 The response for each of the certificates in a request consists of 

• target certificate identifier 

• certificate status value 

• response validity interval 

• optional extensions 



15 



20 



The certificate status value of a response is defined as follows. "Good" indicates a 
positive response to the status inquiry. "Revoked" indicates that the certificate has been 
revoked. "Unknown" indicates that the responder does not know about the certificate 
being requested. 

There are two response validity intervals. "ThisUpdate" indicates the time at which the 
status being indicated is known to be correct. "NextUpdate" indicates the time at which 
newer information will be available about the certificate status. If "NextUpdate" is not 
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set, the responder is indicating that newer revocation information is available all the 
time. 

Prior to accepting a signed response as valid, OCSP clients should confirm that 

• The certificate identified in a received response corresponds to the one 
identified in the request 

• The signature on the response is valid. 

• The identity of the signer matches the intended recipient of the request. 

• The signer is currently authorized to sign the response. 

• The time <6 ThisUpdate" is sufficiently recent. 

• The time "NextUpate" is greater than the current time if it is set. 

Both of the CRL and OCSP mechanisms require the certificate verifier to obtain the 
revocation information from a trusted third party to check the status of a public-key 
15 certificate. That could be a significant burden to applications relying on public-key 
cryptography for security. 

A public-key framework being an embodiment of the invention, that avoids the 
certificate revocation in authentication, non-repudiation, and public-key encryption 
20 services will now be described. In this framework, a public-key certificate has an 
extensible expiry date under the control of the certificate owner or his manager. The 
validity of a certificate could be refreshed by the owner or his manager at a regular 
interval according to the security requirements of a given application. The certificate 



5 
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verifiers can check the validity without retrieving the revocation information from the 
CA. This is based on the security building block of a "one-way hash chain". 

A one-way hash chain is constructed by recursively applying an input string to a one- 
5 way hash function, which can be denoted as H l (r) = H(H M (r)) (i = 1,2, . . .) where H°(r) = 
r is the root of the hash chain. According to the feature of one-way hash function, if r is 
chosen randomly and the hash chain is kept secret, given H*(r), it is computationally 
infeasible for anyone except the originator of the hash chain to find the input Hf'^r). 



10 As a basic security building block, a one-way hash chain has been used in some 

applications including one-time password authentication and micro-payment. The one- 
way hash chain generated in the above way could also be bound to a public-key 
certificate as disclosed in X Zhou and K.Y. Lam. "Securing digital signatures for non- 
repudiation". Computer Communications, 22(8) :7 10— 716, Elsevier, May 1999., where 

15 the hash chain is included in a temporary public-key certificate that is generated by an 
ordinary user (and time-stamped by a trusted third party) so that the certificate expiry 
date is extensible under the control of that user. Another application has been proposed 
in S. Micali. "Certificate revocation system". US Patent 6292893, September 2001, 
where the CA updates the certificate status regularly by providing an intermediate hash 

20 value for a validity period to a CRL, with the final value of the hash chain being 
included in the public key certificate. However, in both these proposals a CRL is 
required to allow confirmation of validity. In Zhou and Lam, the temporary public key 
certificate includes matter signed by a private key associated with a further public key 
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which has a public key certificate issued by a trusted third party, the validity of which 
requires confirmation using a CRL in the normal way. In US 6292893, the intermediate 
hash chain value is provided in the CRL. 

The public-key framework of the described embodiment avoids any trusted third 
parties' involvement in confirming the current validity of the public-key certificate once 
the certificate has been issued by the CA. The certificate will be initially not valid for 
use when issued by the CA. Only when the certificate owner releases a chained hash 
value, will it be valid for a limited time from the starting valid date. The certificate 
owner extends the expiry date of his certificate by releasing the chained hash values at a 
regular interval. If the certificate owner wants to invalidate his certificate, he can simply 
abandon the rest of unreleased hash values in the one-way hash chain. The interval for 
refreshing the certificate validity can be defined as short as desired by the certificate 
owner, so that there is no need of certificate revocation during that interval. 

Generation of public-key certificate will now be described, considering first the 
situation that only the certificate owner can control the validity of his certificate. 

A user U's public-key certificate with an extensible expiry date is generated in the 
20 following way. 

1 . U generates a pair of keys: private key SK 0 and public key PKy. 

2. U defines the maximum life time of the key pair (SKu, PK a ) as T, and the 
starting valid date as D. U also selects the time period for refreshing the 
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validity of the key pair as L. Suppose j = T/L is an integer. The refreshing 
points are denoted as D, = D+L, D 2 = D+2*L, . . ., Dj = D+j*L. (The 
certificate's life time and refreshing points are illustrated in Figure 1.) 

3 . U selects a random number r as the root of a one-way hash chain, and 
5 generates the one-way hash chain FF(r) = HOW'^r)) (i = 1,2, . . j). 

4. U sends his public key PK Us the starting valid date D, the last hash value 
IP(r), the hash chain length j, and the refreshing time period L, to the 
certification authority CA. 

5. The CA authenticates U's request for a certificate in an out-of-band method. 
10 6. Then, the CA generates a public-key certificate CERTu - SIGN^OJ, PKy, 

D, H*(r), j, L). For simplicity, other less related information is omitted in 
CERTu. 
7. The CA sends CERTy to U. 

15 Compared with an ordinary public-key certificate, CERTy contains extra data (H(r), j, 
L) which will be used to control the validity of CERTy. 



Once CERTu is generated, this could either be delivered by the certificate owner U 
during a transaction, or be retrieved from a public directory maintained by a third party. 
20 At the starting valid date D, U will release IF 1 (r) to initialize the validity of CERTy, 
which then has an expiry date Dj = D+L. 
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The use of the public-key certificate in digital signatures will now be described. 
Suppose the next refreshing point of CERTy is D e . When U generates a digital signature 
with SKu, he will attach (H^r), i), where i = j - (D c -D)/L, to the signature. The hash 
value release at each refreshing point is illustrated in Figure 1 . 

5 

When a transacting party V wants to verify U's signatures, he first needs to check the 
validity of CERTy. Suppose V holds the OA's public verification key, and the current 
time that V verifies CERTu is D v . V needs to take the following steps to check the 
validity of CERTu. 

10 1 . V verifies the CA's signature on (U, PKu, D, H j (r), j, L). If true, V will be 

sure that U's public key is PKu. The starting valid date is D, the maximum 
life time is T = j*L, the refreshing time.period is L, and the last hash value in 
the one-way hash chain is H?(r). 

2. VchecksthatO<i<j,andIF i (H i (r))===H j (r). (where IF* is the hash 

15 function H applied recursively to H*(r) (j-i) times. If true, V believes that 

IF(r) is a valid hash value in the one-way hash chain ended with H j (r). 

3. V checks that D v <D + Q-i)*L. If true, V concludes that CERTu is valid 
now, and remains valid until D c = D + (j-i)*L. 

20 In such a way, U can control the validity of CERTy by releasing the corresponding H J (r) 
when generating digital signatures. V can check the validity of CERTu without 
retrieving the revocation information from the CA. Thus, certificate revocation can be 
avoided. 
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The random number r serving as the root of the one-way hash chain is critical to the 
security of the above public-key framework. The certificate owner U relies on it to 
control the expiry date of his public-key certificate CERTy. In case that the private key 
5 SKy is compromised, U only needs to destroy the hash chain root r. Then CERTu will 
expire shortly thereafter at the next refreshing point. 

There might be a risk, however, if the hash chain root r and the private key SK^ are 
stored in the same computer system. If the system is broken, both r and SK V will be 
10 compromised. Then, a hacker holding r and SKy can always generate valid signatures by 
refreshing the validity of CERTu until its maximum life time T. 

The following mechanisms may be used to protect the hash chain root r, these 
mechanisms being used by different users having different requirements, as shown in 
15 Fig. 2. 

Ml : Manually Input "r" 

20 The most straightforward approach is to remember the hash chain root r and manually 
input r at the time of refreshing CERTu. After the hash value needed for refreshing is 
generated, r will be erased from the computer system. That will minimize the possibility 
of compromise caused by system break-in. If SHA is used in the generation of one-way 
hash chain, the length of r could be as short as 20 bytes. As r must be random, it might 
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be a bit hard for an ordinary user to memorize a 20-byte random string. Such a 
technique would be appropriate for use with ordinary users U r U n of Fig. 2. 

M2: Protect "i" with Password 

5 

Alternatively, the hash chain root r could be protected with a password. A password, or 
its hash value then serving as a symmetric key for encryption. The encrypted r is stored 
in the local computer system. When CERTy needs to be refreshed, the password is input 
to get the decrypted r. r will be erased soon after use. If DES is used for encryption, the 
10 length of the password could be as short as 8 bytes. As a password is usually not truly 
random and an off-line dictionary attack is also possible, this mechanism for 
safeguarding r is not highly secure. Such a technique would be appropriate for use with 
ordinary users U r U n of Fig. 2. 



15 M3 : Protect "r" Using Security Server 

In this approach, the hash chain root r is be encrypted and stored locally while the secret 
key K for encryption is stored with a security server SS_K. Suppose U has registered 
his password at the security server. Then U and the security server can establish a secure 
20 and authenticated channel with password-based protocols (S. Bellovin and M. Merritt. 
"Encrypted key exchange: Password-based protocols secure against dictionary 
attacks 91 . Proceedings of 1992 IEEE Symposium on Security and Privacy, pages 72-84, 
Oakland, California, May 1992), over which U could upload and download K safely. 
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When a refreshing date is approaching, U retrieves K from the security server, decrypts 
the cipher text of r, and calculates the corresponding chained hash value, after which r 
and K will be erased from the local system. U could optionally update the secret key K 
5 and upload the new key to the security server. 

As the security server does not have the cipher text of r, it does not have the knowledge 
of r. Therefore, only the certificate owner has the control on the validity of his 
certificate. 

10 

This architecture is shown for users U^K - U n K in Fig. 2 and is especially good for 
corporate clients in which a security server will centrally manage the secret key for each 
client. As the security server only needs to serve its internal clients, its connection to the 
Internet could be tightly controlled to minimize the risk of compromise. As the 
15 corporate clients rely on the security server in the extension of expiry date of their 
certificates, it is important to ensure that the security server is well configured to 
function properly. 

As just described, the hash chain root r is generated by the certificate owner U. 
20 Therefore, U has the full control of the validity of CERTu until CERT V reaches its 

maximum life time T. This can only address the need of certificate revocation caused by 
the compromise of private keys. However, a public-key certificate may have to be 
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revoked by the manager of the certificate owner for other reasons such as termination of 
job or change of name. 

To address this problem the hash chain root may be generated by a security server SS_r, 
5 which will be administered by the manager of corporate users. This is shown for users 
U^r - U n _r in Fig. 2. The process of certificate generation will be changed as follows. 
L U generates a pair of keys: private key SK V and public key PK^. 

2. Suppose U has registered his password at the security server. Then U could 
sends the request of a certificate for corporate use, together with his public 

10 key PKu, to the security server over a secure and authenticated channel with 

password-based protocols (as disclosed in [Bellovin and Merrit], above). 

3. According to the corporate security policy, the security server defines the 
maximum life time of U's certificate as T, and the starting valid date as D. It 
also selects the time period for refreshing the validity of the certificate as L. 

15 4. Suppose j = T/L is an integer. The security server selects a random number r 

as the root of a one-way hash chain, and generates the one-way hash chain 
H i (r) = H(H i - l (r)) (i = 1,2, j). 

5. The security server sends U's public key PKu, the starting valid date D, the 
last hash value HP(r), the hash chain length j, and the refreshing time period 

20 L, to the certification authority C A. 

6. The CA authenticates the security server's request for generating a public- 
key certificate in an out-of-band method. This will prevent U from 
requesting a public-key certificate for corporate use without authorization. 
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7. The CA may further challenge U in an out-of-band method to ensure U holds 
the corresponding private key. This will prevent the security server from 
requesting a public-key certificate in the name of U who is unaware of it. 

8. Then, the CA generates a public-key certificate CERTy = SIGN CA (U, PK^, 
D,H?(r),j, L). 

9. The CA sends CERTy to the security server. 

10. The security server forwards CERTy to U. 



When a refreshing date is approaching, the security server distributes the corresponding 
10 hash value to U. Suppose the next refreshing date of CERTu is D c . The security server 
calculates IT(r) from r where i = j - (D c -D)/L, and distributes (JF(r),i) to U. No 
protection is needed in distribution. U can easily verify H\r) is the hash value to be 
released on the date D e by checking whether j-i = (D e -D)/L and H^(H*(r)) - H j (r). 



15 If the security server wants to revoke U's certificate for some reason instructed by the 
corporate management, the security server can do so by stopping release of U's hash 
values, thus CERTy will expire soon at the next refreshing point. If U suspects a 
compromise of his private key, U could send a request to the security server for stopping 
distribution of the next hash value. 

20 

The security server's role in this embodiment is fundamentally different from the CA's 
role in certificate revocation. 
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• The security server only needs to communicate with the certificate owners 
while the CA needs to make the revocation information available to any 
potential certificate verifier. 

• The chained hash values released by the security server need no protection 

5 while the authenticity and integrity of the revocation information released by 

the CA need to be protected. 



In the described embodiment, a user or his manager can control the validity of his 
public-key certificate and others can check the validity of such a certificate without 
10 retrieving the revocation information from the CA. This improves the efficiency in 

authentication, non-repudiation, and public-key encryption services. Some applications 
will now be described: 



Authentication 

15 

Authentication is a basic security service that provides protection against masquerade. 
This consists of entity authentication that verifies a claimed identity, and data origin 
authentication that verifies the source and integrity of a message. Digital signature is an 
important security mechanism to support authentication. In authentication services, the 
20 signature verifier will use the signer's public key to verify the signature. More 

importantly, the verifier should check whether the signer's public key is valid at the 
time of verification. 
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The signer's public key is usually bound to the signer's identity in a public-key 
certificate issued by the CA. If the public-key certificate is constructed with an 
extensible expiry date as described above, it becomes very efficient to check the validity 
of the certificate. 

5 

Suppose the signer U generates a digital signature a using his private key SK U5 and the 
next refreshing date of CERTy is D c . U sends a and (H^r), i) 9 where i = j - (D 6 -D)/L, to a 
transacting party V for authentication. 

10 As the validity of CERTy is decided by the hash value released by U (before CERTy 
reaches the maximum life time T defined in CERTu), V only needs to check whether 
H*(r) is the hash value that extends the expiry date of CERT\j to D e . If so, V can use 
CERTy safely before its current expiry date D c to verify U's signatures. 

1 5 Non-Repudiation 

Non-repudiation is another basic security service that provides protection against false 
denial of having been involved in an electronic transaction. It creates, collects, validates, 
and maintains cryptographic evidence in order to support the settlement of possible 
20 disputes. Digital signature is one of the most convincing types of cryptographic 

evidence. However, there are stronger security requirements when digital signatures are 
used for non-repudiation purpose. 
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As there exists the possibility of private key compromise and thus the forgery of digital 
signatures, there is a need for the revocation of the corresponding public-key certificate. 
Then, signatures generated after certificate revocation will be regarded as invalid. On 
the other hand, all signatures generated before certificate revocation should remain 
5 valid, thus can be used in the settlement of disputes that may arise at a time well after 
the end of a transaction. 

With the described embodiment, two approaches to support a non-repudiation service, a 
trusted time-stamping service and a forward-secure digital signature scheme are 
10 provided. 

For trusted time-stamping, suppose the signer U generates a digital signature a using his 
private key SKy. Different from the authentication service, U should get a trusted time- 
stamp D g on a, denoted as SIGN TCA p g , cr), from a time-stamping authority (TSA). 
15 Suppose the next refreshing date of CERT 0 is D e . U sends SIGN^CDg, a) and (fT(r), i), 
where i = j - (D e -D)/L, to a transacting party V as non-repudiation evidence. 

As discussed above, with (H^r), i), it is easy for V to check whether CERT 0 is valid 
until the date D c . Suppose V holds the TSA's public verification key. Then, V could use 
20 . SIGN TSA (D g , cr) to further check whether a is U's signature generated before i.e., D g 
< D e . If so, V could accept SIGN TSA (Dg, a), (ff(r), i), CERT 0 safely as valid non- 
repudiation evidence. They could be used to prove to any third party that U's signature 
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a was generated while the corresponding certificate CERTy was still valid, and thus 
undeniable. 

U could further extend the expiry date of CERTy to D e +L by releasing (tf' l (r), i-1) when 
5 D c < Dj, or let CERT\j to expire at D 0 by destroying the unreleased one-way hash chain. 
In either case, it will not affect the validity status of a. 



This approach avoids the CA's involvement for certificate revocation. However, it still 
relies on the trusted third party TS A to provide the time-stamping service. 

10 

A forward-secure digital signature approach is more efficient as it avoids the 
involvement of both the C A and the TS A. 

Forward-secure digital signature schemes (M. Bellare and S. Miner. (f A forward-secure 
15 digital signature scheme Lecture Notes in Computer Science 1666, Advances in 
Cryptology: Proceedings of Crypto'99, pages 431-438, Santa Barbara, California, 
August 1999; H. Krawczyk. ''Simple forward-secure signatures from any signature 
scheme Proceedings of 7th ACM Conference on Computer and Communications 
Security, pages 108— 1 15, Athens, Greece, November 2000), which update the private 
20 signing key at regular intervals while the public key is fixed throughout the lifetime of 
the certificate preserve the validity of past signatures without using a trusted time- 
stamping service even if the current private key has been compromised. However, such 
schemes cannot address the issue on signature forgery with the subsequent signing keys 
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derived from the current compromised one. 

With reference to Figure 3, a forward-secure digital signature scheme using the 
embodiment of the invention will be described. The scheme uses four functional 
5 components: FWKG for key generation, FWUPD for private key update, FWSIGN for 
signing, and F WVER for signature verification, and details of these components may be 
found in the prior art mentioned above. FWKG generates the public key PK and the 
root private key SK^. The lifetime T is divided into j intervals as before, each interval k 
of length L being associated with a value of the hash chain H k (r), PK will be certificated 
10 by the CA, together with (0(f), j, L). Each interval I has also associated therewith an 
interval private key SK k . 

FWUPD updates the private key at each refreshing point as follows: SK X = 
FWUPDCSKs) at point D, SK 2 - FWUPDCSKJ at point D l9 . . SJ^ = FWUPDCSK^) at 
15 point D H as shown in Figure 3. FWUPD is a one-way function in the sense that no one 
can derive SK^ from SKj but computing SKj from SKj., is easy. Once the private key is 
updated, the old private key must be erased, thus nobody can derive any past private 
keys from the current one. 

20 According to the time of signature generation, the digital signatures generated under this 
mechanism can be classified into three types as illustrated in Figure 3: signatures of past 
time periods, signatures of current time period, and signatures of subsequent time- 
periods. 
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Suppose the current private key is SK,.. The signer U must attach the current time D g to 
the message M that is to be signed, denoted as FWSIGN(M, D g> SKJ. Suppose the next 
refreshing point of CERTy is D e . U will attach (H*(r) 5 i), where i = j - (D e -D)/L, to the 
5 above signature. 

With F WSIGN(M, D g , SKJ, (H^r), i), and CERT U5 the verifier V is able to check , as 
before, whether CERT V is valid until D 6 and D g <> D c . If so, V believes that F WSIGN(M, 
D g , SIQ was generated at the time that CERTu was still valid. V further checks ITs 
10 signature FWSIGN(M, D g> SKJ which requires D g as an input of FWVER. The 

verification will fail if D g ^ or D g > D e . That means the private key of the current 
time period can only be used to generate valid signatures of that time period. 

Put another way, the interval private keys SK are arranged such that an earlier interval 
15 key cannot be derived fiom a later one and the hash values are arranged so that a later 
interval hash value cannot be derived from an earlier one. Used together, the interval 
private key and interval hash value can relate to one interval only and since it is not 
possible to derive both a later hash value and a later private key or both an earlier hash 
value and an earlier private key from the current hash value and current interval private 
20 key if these are compromised, transactions in all past and future intervals remain 
secure. 
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If FWSIGN(M, D g3 SKJ, (IT(r), i), and CERTupass the above verification, they could 
serve as valid non-repudiation evidence. 



If U suspects the compromise of his current private key SK,, he could let CERTu to 
5 expire at D c by destroying the unreleased one-way hash chain. The attacker cannot 
derive past private keys from the compromised current one, and thus cannot forge valid 
signatures of past time periods. Although the attacker could derive the subsequent 
private keys from the compromised current one, he cannot use them to forge valid 
signatures of subsequent time periods since CERTy has expired. The risk of signature 
10 forgery in the current time period could be well controlled if the refreshing time period 
L is carefully defined according to the individual's security requirement, which is more 
flexible than the CRL-based revocation mechanism whose update interval must be 
acceptable to all certificate users. 



15 

Public Key Encryption 



In the described embodiment, the procedure for public-key encryption is slightly 
different. When a user signs a message, he can attach (H^r), i) to his signature for 
20 verifying CERTu. When a user encrypts a message, he has to first obtain such 
information from the intended recipient. 
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In the normal PKI, the user doing public-key encryption first needs to obtain the 
revocation information from the issuing CA in order to check the validity of the 
intended recipient's certificate. In the described embodiment, the CA will not provide 
any revocation information once the certificate has been issued. Instead, the certificate 
will have an extensible expiry date which is under the control of the certificate owner or 
his manager. The user doing encryption has to obtain the information of current expiry 
date from the certificate owner. 

The process of public-key encryption could be described as follows. 

1 . The user doing encryption sends an enquiry to the intended recipient about 
the status of his public-key certificate CERTu. 

2. If CERTy has expired, the intended recipient replies with an expiry status. 
Otherwise, the intended recipient provides (IT(r), i), which indicates CERTu 
will be valid until the refreshing point D j4 = D + (j-i)*L. No protection is 
needed in distribution of (H'(r), i). 

3. The user can check whether tf(r) is the matching hash value that extends the 
expiry date of CERTy to D^. If the current time is earlier than D^, the user 
will be sure that CERTy is still valid, thus the corresponding public key can 
be used safely for encryption. 

4. The user sends the encrypted message to the intended recipient. 

X.509 is an industry standard which defines the format of a public-key certificate and 
this is illustrated in Fig. 4. The applicability of our new public-key framework is closely 



WO 2004/032416 PCT/SG2002/000198 

32 

related to the issue on whether the extra data for an extensible expiry date can be 
integrated into the existing X.509 certificate format with the mhiimum impact on 
interoperability. 

5 The X.509 v3 certificate basic syntax includes version number, serial number, issuer's 
signature algorithm identifier, issuer name, validity period, subject name, subject public 
key information, issuer unique id, subject unique id, and extensions. The most flexible 
part of a X.509 v3 certificate is its "extensions" field. Each extension contains an 
extension id and the extension value, and may be designated as critical or non-critical. 

10 

The extensions defined for X.509 v3 certificates provide methods for associating 
additional attributes with users or public keys and for managing the certification 
hierarchy. The X.509 v3 certificate format also allows communities to define private 
extensions to carry information unique to those communities. Current standard 
15 extensions are authority key id, subject key id, key usage, certificate policies, subject 
alternative name, issuer alternative name, basic constraints, name constraints, policy 
constraints, and extended key usage. 

To support the extensible expiry date, the data (H?(r), j, L) should be included in the 
20 certificate. From the structure of a X.509 v3 certificate, there are three possible 
extensions into which the data (H J (r), j, L) could be integrated. 
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The first option is "private extension". This extension could be defined locally, and 
allows X.509 v3 certificates to include more attributes. A new private extension could 
be defined that specifies the data format as (H*(r), j, L) to support the extensible expiry 
date. 

The second option is "subject key id". The subject key id extension provides a means of 
identifying certificates that contain a particular public key. As the hash chain root r is 
randomly selected when generating a public-key certificate, the data (H j (r), j, L) could 
be regarded as a subject key identifier that uniquely links to the public key. 

The third option is "subject alternative name". The subject alternative name extension 
allows additional identities to be bound to the subject of the certificate. The data (H?(r), 
j, L) could be regarded as an additional identity bound to the subject in the form of 
locally defined other name. 

Having now fully described the invention, it should be apparent to one of ordinary skill 
in the art that many modifications can be made hereto without departing from the scope 
as claimed. 
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CLAIMS 



1 . A method of performing a public/private key operation comprising the steps 
of: 

5 (a) generating a private and public key pair, the public key having a 

lifetime; 

(b) selecting a plurality of intervals within the lifetime and a plurality of 
respective identifiers, each interval being associated with a said 
identifier; and 

1 0 (c) having a trusted third party generate a public key certificate which 

includes the public key and a final identifier, the identifiers being 
selected so that it is relatively difficult to derive an identifier 
associated with a said interval from the final identifier but relatively 
easy to derive the final identifier from an identifier associated with a 

15 said interval, a said identifier being provided by a user with any 

matter signed or otherwise operated upon using the private key in the 
associated interval to confirm the validity of the certificate in that 
interval. 

2. A method as claimed in claim 1 wherein a user of the private key holds the 
20 certificate. 

3. A method as claimed in claim 1 wherein the certificate is held in a public 
location. 
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4. A method as claimed in any one of the preceding claims wherein one or 
more identifiers or means from which the identifiers may be generated is/are 
stored on a remote server. 

5. A method as claimed in claim 4 wherein, at the time a user wishes to encrypt 
5 matter using the private key, the user obtains the identifier for the current 

period from the server. 

6. A method as claimed in claim 4 wherein at the time a user wishes to encrypt 
matter using the private key, the user obtains said means from the server and 
generates the identifier using the means. 

10 7. A method as claimed in claim 5 or claim 6 wherein the user and server 
communicate via a secure channel. 
8. A method as claimed in any one of the preceding claims wherein the 

identifiers are generated by recursive application of a one-way hash function 
to a root. 

15 9. A method as claimed in any one of the preceding claims wherein a third 

party operates on the current interval identifier to derive the final identifier to 
confirm the validity of the certificate in the current interval. 

10. A method as claimed in any one of the preceding claims wherein the user 
obtains a time stamped version of the encrypted matter to be accompanied by 

20 the identifier. 

11. A method as claimed in claim 10 wherein the third party operates on the 
current interval identifier to derive the lifetime identifier to confirm the 
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validity of the certificate in the current interval and that the timestamp is 
within the current interval. 

12. A method as claimed in any one of the preceding claims wherein the private 
key has validity within a time period and the user sends a time of encryption 

5 with the encrypted matter. 

13. A method as claimed in claim 12 wherein third party operates on the 
current interval identifier to derive the final identifier to confirm the validity 
of the certificate in the current interval and that the time of encryption is 
within the time period. 

10 14. A method as claimed in any one of the preceding claims wherein, each 

interval has associated therewith an interval private key, the interval private 
keys being each usable together with the public key in a public/private key 
encryption/decryption operation, the interval keys being such that it is 
relatively easy to derive a later interval key from an earlier interval key but 

15 relatively difficult to derive an earlier interval key from a later one. 

15. A method as claimed in any one of the preceding claims wherein a third 

party wishing to confirm the validity of the certificate requests from the user 
the identifier of the current time period and determines if the final identifier 
of the certificate can be derived from the current identifier. 

20 16. A method as claimed in claim 1 5 wherein the third party uses the public key 

verified by the certificate to encrypt matter to send to the user. 
17. A method of conducting a public key transaction comprising the steps of: 
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(a) generating a public and private key pair, the private key being held 
by the user and the public key being accessible to a party to the 
transaction and having associated therewith a public key certificate 
issued by a trusted third party; 
5 (b) sending to the party matter signed or otherwise operated upon using 

the private key by the user together with a matter identifier; 

(c) the certificate including a certificate identifier , the identifiers being 
such that it is relatively easy to derive the certificate identifier from 
the matter identifier but relatively difficult to derive the matter 

10 identifier from the certificate identifier; and 

(d) operating on the matter identifier provided by the user to derive the 
certificate identifier to confirm the validity of the certificate. 

18. A public key certificate issued by a trusted third party comprising a public 
key, a final identifier and means defining validity periods between a start 

15 date and a finish date, a plurality of identifiers not forming part of the 

certificate each being associated with a said validity period and arranged to 
accompany matter signed or otherwise operated upon by the user using a 
private key associated with the public key within the respective validity 
period and wherein the plurality of identifiers are selected so that it is 

20 relatively easy to derive the final identifier from one of the plurality of 

identifiers but relatively difficult to derive any of the plurality of identifiers 
from the final identifier, whereby the validity of the public key certificate 
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within the validity period may be confirmed by operating upon the identifier 
provided by the user with the matter . 
19. A certificate as claimed in claim 18 wherein the identifiers are the product of 
the recursive application of a one-way hash function to a root 
5 20. A certificate as claimed in claim 1 8 or claim 1 9 wherein said means include 

a start date and the number and duration of renewal intervals. 

21 . A certificate as claimed in any one of claims 1 8 to 20 wherein the identifier 
and said means are integrated into one or more extensions of the certificate. 

22. A certificate as claimed in claim 22 wherein said one or more extensions 
10 comprise at least one of: 

(a) a private extension; 

(b) a subject key id; 

(c) a subject alternative name. 

23 . A certificate as claimed in any one of claims 1 9 to 23 wherein the certificate " 
15 is constituted using X.509. 

24. A public/private key cryptography framework in which matter operated upon 
using a private key of a public and private key pair is associated with a 
separate authentication which accompanies the matter, the authentication 
being related to a verifier, the verifier and public key being available to a 

20 recipient of the encrypted matter and accompanying authentication in the 

form of a public key certificate issued by a trusted third party and the 
arrangement being such that the verifier may be derived from the 
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authentication but not vice versa to confirm the validity of the public key 
certificate. 

25. A framework as claimed in claim 24 wherein the public key and verifier are 

bound together in a public key certificate. 
5 26. A framework as claimed in claim 24 or claim 25 wherein the certificate once 

generated resides with a user of the private key and accompanies any 

encrypted message sent by the user. 
27. A method of performing a public/private key operation comprising the steps 

of: 

1 0 (a) generating a public key and a root private key, the public key having 

a lifetime; 

(b) operating on the root private key to generate a respective plurality of 
interval private keys, the interval private keys being each usable 
together with the public key in a public/private key operation; 
15 (c) selecting a plurality of intervals* within the lifetime and a respective 

plurality of identifiers, each interval being associated with an 
identifier and a said interval private key; 

(d) associating the public key with a final identifier; 

(e) the identifiers being such that it is relatively difficult to derive an 
20 identifier associated with a said interval from the final identifier but 

relatively easy to derive the final identifier from an identifier 
associated with a said interval ; and the interval keys being such that 
it is relatively easy to derive a later interval key from an earlier 
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interval key but relatively difficult to derive an earlier interval key 
from a later one. 

28. A method as claimed in claim 27 wherein the public key and final identifier 
form part of a public key certificate issued by a trusted third party. 
5 29. A method as claimed in claim 27 or claim 28 wherein the identifiers are 

generated by recursive application of a one-way hash function to a root 

30. A method as claimed in any one of claims 27 to 29 wherein, within a current 
said interval, a user sends, to a third party, matter encrypted using the private 
key associated with the current interval, the identifier associated with the 

1 0 current interval is provided with the encrypted matter. 

31. A method as claimed in claim 3 0 wherein the third party operates on the 
current interval identifier to derive the final identifier to confirm the validity 
of the private key and hash value in the- current interval. 
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Figure 1. 
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